Summary of changes

hciEvtProcessMsg parses incoming hci command packets. In doing so, it dynamically determines the length of the packet body by reading a byte from the packet header.

• mbed-os/connectivity/FEATURE_BLE/libraries/cordio_stack/ble-host/sources/hci/dual_chip/hci_evt.c

  Line 2748 in 54e8693

  BSTREAM_TO_UINT8(len, pEvt);

Then, hciEvtProcessCmdCmpl is called. A buffer is allocated to hold the packet, the length of which is determined by the sum of this 8-bit integer and the length of a structure to hold some metadata but without 3 bytes that are assumed to exist and have already been read.

• mbed-os/connectivity/FEATURE_BLE/libraries/cordio_stack/ble-host/sources/hci/dual_chip/hci_evt.c

  Lines 2685 to 2695 in 54e8693

  	const uint8_t structSize = sizeof(hciUnhandledCmdCmplEvt_t) - 1 /* removing the fake 1-byte array */;
  	const uint8_t remainingLen = len - 3 /* we already read opcode and numPkts */;
  	const uint8_t msgSize = structSize + remainingLen;
  	pMsg = WsfBufAlloc(msgSize);
  	if (pMsg != NULL) {
  	pMsg->hdr.param = opcode;
  	pMsg->hdr.event = HCI_UNHANDLED_CMD_CMPL_CBACK_EVT;
  	pMsg->hdr.status = HCI_SUCCESS;
  	/* copy the payload */
  	memcpy(pMsg->unhandledCmdCmpl.param, p, remainingLen);

This can be exploited in 2 ways, the first of which sets a len < 3. This means that

len = 0x2
remainingLen = len - 0x3 = 0xff (=> write amount)
msgSize = remainingLen + sizeof(hciUnhandledCmdCmplEvt_t) = 0xff + 0x5 = 0x4 (=> buffer size)

The other takes advantage of the fact that msgSize is a uint8_t.
Picking a len = 0xff leaves:

len = 0xff
remainingLen = len - 0x3 = 0xfc (=> write amount)
msgSize = remainingLen + sizeof(hciUnhandledCmdCmplEvt_t) = 0xfc + 0x5 = 0x1 (=> buffer size)

This leads to a too small allocation for the message buffer and the following call to memcpy() results in a buffer overflow.

This fix addresses both of these issues by:

1. Ignoring packets with a length less than 3
2. Changing msgSize to be a uint16_t

Impact of changes

Migration actions required

Documentation

None

Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[x] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR